- Le Fortran développé entre 1954 et 1957 par lui et son équipe au sein d'IBM. Le Fortran, que l'on aime ou que l'on aime pas, a su par la suite évoluer et sa dernière mouture est toujours très utilisée en calcul intensif.
- La notation BNF (Backus-Naur Form) en 1959 permet de décrire la grammaire d'un langage de programmation indépendamment de ce langage. Cette notation est toujours très utilisée de nos jours. A l'origine, John Backus l'a introduite pour définir l'Algol.
- Il est en effet l'un des membres actif du comité international de l'Algol 58, puis de l'Algol 60 . Ce langage a rapidement été utilisé dans les années 60 par les universitaires pour décrire des algorithmes. Il a, par exemple, été le premier à utiliser la paire : "begin end" pour délimiter les blocs. Aujourd'hui au musée des langages, il a fortement marqué ses successeurs, dont le Pascal.
NdM : les compilateurs libres gfortran et Free Pascal sont disponibles, pas encore Algol dans la GNU_Compiler_Collection ?
Aller plus loin
- John Backus sur Wikipedia (17 clics)
- L'annonce de presse du Monde Informatique (6 clics)
- Le Fortran (15 clics)
- La notation BNF (13 clics)
- L'Algol (5 clics)
- Le Pascal (1 clic)
# Le Fortran
Posté par plic . Évalué à 4.
J'utilise du fortran 77 tous les jours. Même si on peste des fois, ce langage est très facile à apprendre.
Adieu John...
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: Le Fortran
Posté par Troy McClure (site web personnel) . Évalué à 6.
DO I=1.42 est une assignation à la variable "DOI"
alors que
DOI=1,42 est une boucle sur I
c'est pas génial ça ?
Au fait, y'a des affreux qui veulent faire mourrir le fortran:
http://www.fortranstatement.com/cgi-bin/petition.pl
[^] # Re: Le Fortran
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Je n'arrive plus à relire ce fortan qui est de la programmation spaghetti et qui a forgé la légende du fortran.
J'ai ensuite utilisé le fortran 4x puis 77 de 1979 à 2002.Il est devenu un langage fort pratique, très commode pour gérer les chaines de caractères et surtout, il a inclus l'instruction : "implicit none".
Je me suis aperçu que l'on gagnait toujours du temps avec "implicit none" dès que l'on avait un programme de plus de 100 lignes. Les types implicites du Fortran basés sur le premier caractère de la variable : [i..n]=integer, [c]=complex, [d]=double précision ont conduit à la perte d'une sonde spatiale à cause de ceci :
DO 100 I=1,1000
......
100 CONTINUE
Ce qui signifie, faire 1000 fois la boucle jusqu'à l'étiquette 100.
Il se trouve que la virgule avait été remplacée par un point et le compilateur a compris :
DO100I=1.1000
Il a créé la variable double précision do100i et lui a attribué la valeur 1.1
Après cette affaire la NASA a interdit les déclarations implicites et a lancé un concours qui a abouti à ADA.
[^] # Re: Le Fortran
Posté par let antibarbie = xp <- xp - 1 . Évalué à 2.
Pour moi John, il a fait un truc bien, c'est la notation BNF, après le Fortran, vite vite tournons la page :-p
[^] # Re: Le Fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
> des paradigmes intéressants
Tu as lu du Fortran 95 ? Si tu sais lire de l'Ada ou du Pascal, le Fortran est quasiment pareil. Pas d'accolade {} ni de parenthèses () à tour de bras, des beaux "begin ... end".
Ensuite, j'aime beaucoup les langages de scripts mais on ne peut pas comparer le Fortran avec le Ruby. Cela n'a rien à voir. En Fortran, tout a été fait pour programmer en adressage statique, tous les passages de paramêtres se font par adresse, les fonctions ne sont pas récursive par défauts. Ce n'est pas pour se faire plaisir, c'est une question de performance et de parallèlisme.
OCaml est très bien mais un non informaticien arrive-t-il a programmer dans ce langage ? Et quelles sont les performances dOCaml dans le calcul parallèle ?
Fortran est un langage spécialisé dans le calcul scientifique. Si il était si mauvais que cela, il aurait été remplacé depuis longtemps. Or c'est un des rares langages de la préhistoire qui soit encore là et qui a su évoluer en profondeur.
J'ai été il y a quelques temps à un séminaire sur la performance, notament sur la problématique de la machine pétaflop que les constructeurs envisagent pour peu.
Tu fait un programme et tu le fait tourner sur 10 coeurs et tu regarde sa performance par rapport à un coeur. Tu fait de même avec 100 ou 1000 coeurs. D'après le conférencier (et mes souvenirs), les programmes utilisant OpenMP tiennent bien entre 10 et 100 coeurs. Entre 100 et 1000 coeurs, les programmes qui tiennent la charge utilisent généralement MPI. Très peu de programme dépasse les 1000 coeurs sans s'effrondrer. Or il est envisagé bien plus de 1000 coeurs pour une machine pétaflop.
Les constructeurs travaillent énormément pour arriver à faire une machine pétaflop mais, pour qu'une application puisse tirer le maximum d'une telle machine, il faut d'après changer notre manière de coder.
Si tu regardes du coté de Fortran 2008, il y a justement cette problèmatique du calcul matriciel parallèle au coeur des extensions.
Je veux bien, Ruby s'est très bien mais c'est pas avec Ruby que tu calcule la météo du lendemain, ni que tu fait une prédiction pour les 50 ans qui viennent du réchauffement climatique, ou que tu calcule la propagation des ondes sismiques dans un bassin aluvionnaire entouré de montages (cas intéressant car il y a des phénoménes d'amplification du à la géométrie et à la composition des sols).
Bref, il est idiot de vouloir programmer un site web dynamique en Fortran. De même, ne demandons pas aux langages de script de faire tourner un calcul sur une machine Itanium à 4096 coeur.
Je trouve qu'il y a de plus en plus d'offre de compilateur Fortran 90 (95) sur le marché. Ma prédiction est que vu les problèmes écologiques à venir, le Fortran n'est pas près de prendre sa retraite.
[^] # Re: Le Fortran
Posté par - - . Évalué à 2.
il est sain de rappeler que Fortran ne disparaît _pas_ et qu'il n'existe PAS qu'une seule informatique.
[^] # Re: Le Fortran
Posté par Troy McClure (site web personnel) . Évalué à 4.
Mouais mouais un peu comme windows, ou Matlab pour rester dans le domaine du calcul scientifique (en voilà un autre langage bien batard que celui de matlab)
A mon sens Fortran est surtout resté parce que ses utilisateurs ne sont pas informaticiens (et ils ne se rendent donc pas compte de l'espèce d'horreur qu'est le mix de f77 et de f90 que pratiquent aujourd'hui la plupart d'entre eux), et qu'ils n'ont pas envie d'apprendre un autre langage. C'est aussi le seul langage qui soit "dédié" au calcul scientifique. Pourtant il n'a pas grand chose à proposer à part un support natif des tableaux multidimensionnels, et le fait que le code compilé par un compilo f77 est vraiment rapide (pour le f90 c'est déjà beaucoup moins clair)
Le f90 est au f77 ce que le c++ est au c ( et même un peu plus). En gros il n'a rien à voir, mis à part qu'on peut encore coller des bouts de f77 au milieu d'un code f90 et ça compilera. Je trouve qu'ils auraient du carrement faire un nouveau langage plutot que cet espèce de frankenstein qui ne gère pas les lignes de plus de 132 caractères (c'était 80 en f77 mais les visionnaires concepteurs de f90 ont décidé que 132 should be enough for everyone. Alors il y des compilateurs qui arrêtent de lire après le 132ème car. Que du bonheur à débugger). f90 a aussi gardé l'espère d'ignominie qu'est le système d'i/o de f77, qui était surement très adapté au temps des cartes perforées, mais le monde a changé depuis. On a aussi inventé la ligne de commande entre temps, mais c'est dommage f90 ne permet pas de lire les arguments de la ligne de commande. Je ne m'étendrais pas sur le support des chaines de caractères, qui est éminement rustique et peu orthodoxe. Petit détail esthétique: l'usage du '%' pour accèder aux membres d'une structures, là où tous les autres langages utilise un '.'
Tout ça pour dire que je trouve que le cas du fortran est desespéré. Que la bête meure! et vive Fortress!
[^] # Re: Le Fortran
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 2.
Bien propre, les compilateurs de Sun font des merveilles pour paraleliser le tout. Et pour répondre à la critique sur les problèmes d'I/O etc... on interface notre code avec du Python...
[^] # Re: Le Fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Pour les entrées sorties, cela ne m'a jamais géné. Ce n'est pas du printf à la C mais les printf du C sont parait-il soumis au buffer overflow...
Au niveau de la ligne de commande, tu peux avoir les arguments depuis tous les compilateurs que j'ai croisé. Certes, cela n'était pas normalisé . Justement, ce manque est résolu avec le F2003. A ce sujet là, Java est contre la ligne de commande...
Quand au %, certes c'est pas très beau mais il ne pouvait pas prendre le . car celui-ci est déjà pris pour les opérateurs. En effet, tu peux définir autant d'opérateur que tu veux en fortran avec des petits noms, par exemple un opérateur 'scalar' qui serait le prodiut scalaire de deux vecteurs ou de deux tenseurs. En gros un opérateur qui te donne le résulta d'une mesure sur un objet. Tu l'utilise ensuite en écrivant :
m = X .scalar. Y
Et lorsque tu programme un code de cacul avec plein de formule, c'est hyper pratique de coder ainsi. Dans les autres langages, je ne connais pas d'équivalent aussi pratique et parlant. Je ne parle pas de la surcharge de l'operateur * qui représente un produit mais lequel ?
Bref, surcharger * rend souvent le code illisible, il est bien plus pratique de définir ses propres opérateurs.
Tiens un truc bien, en Fortran 90, pas de ses fichiers d'en tête à la Ada ou tu dupliques tout ou à la C qui fait des inclusions récusives qu'il faut bidouiller avec des #define... Non, c'est le complateur qui en analysant ton code te génère ton fichier d'en tête !
Comme quoi, la diversité n'est pas plus mal.
[^] # Re: Le Fortran
Posté par let antibarbie = xp <- xp - 1 . Évalué à 1.
OCaml, l'avenir du fortran ? :-) non non je ne trollerai pas là dessus,
mais ça méritait d'être signalé.
[^] # Re: Le Fortran
Posté par l0stman . Évalué à 2.
*tousse* *tousse*
[^] # Re: Le Fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
J'avais remarqué qu'il y avait des personnes qui étaient à la fois dans le comité Ada et dans celui de Fortran. Cela n'empêche pas Fortran de ne pas suivre bêtement Ada mais d'avoir sa propre trace. Par exemple, les pointeurs introduits en Fortran 90 sont petits à petits éliminés au profit d'objet "allocatable" bien plus facile à gérer pour un compilateur en terme de ressource.
Je te conseille d'aller voir du coté de la norme Fortran 2003 pour te rendre compte par toi même. Si tu veux développer un client de courriel ou un traitement de texte, passe cependant ton chemin. Le Fortran est clairement orienté calcul scientifique et malgré mes réticences au début, il faut avouer qu'il remplit pas mal son rôle.
http://en.wikipedia.org/wiki/Fortran
Un présentation faites par l'IDRIS
http://www.idris.fr/data/cours/lang/fortran/f2003/Fortran_20(...)
[^] # Re: Le Fortran
Posté par lasher . Évalué à 2.
[^] # Re: Le Fortran
Posté par benoar . Évalué à 4.
http://en.wikipedia.org/wiki/Cobol#COBOL_2002_and_object-ori(...)
[^] # Re: Le Fortran
Posté par med . Évalué à 3.
[^] # Re: Le Fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Le F2003 permet de faire de la programmation objet simple. Pour les projets auquels j'ai participé, c'est suffisant et cela permet d'éviter d'émuler l'objet.
Il faut bien voir que programmer en objet n'est pas toujours bon pour la performance. La programmation objet a un peu trop tendance a crée trop d'objet intermédiaire avec de l'allocation et de la dé-allocation de la mémoire.
Encore une fois, le Fortran est un langage spécialisé conçu pour la performance, pas pour le "Desktop".
[^] # Re: Le Fortran
Posté par lasher . Évalué à 1.
[^] # Re: Le Fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Soyons honnête, le Fortran 95 et maintenant 2003 sont bien plus lisible que du C. Evidement, je ne parle pas pour une personne qui fait du C toute la journée !
Regardes un peu le pdf que propose l'IDRIS sur le Fortran 2003 et tu verras qu'il n'a pas à rougir du C pour son objectif à lui, c'est à dire le calcul intensif.
[^] # Re: Le Fortran
Posté par - - . Évalué à 1.
à la mode par plaisir.
il faut du temps pour que les outils de calculs, les projets et les gens intègrent les évolutions.
mais je confirme que fortran est toujours d'actualité, qu'il est dans le milieu industriel et académique et non on ne fait pas de migration pour s'en débarrasser, j'ai encore pléthore de progiciels conçus et pensés pour travailler avec fortran, et ils évoluent régulièrement.
[^] # Re: Le Fortran
Posté par lasher . Évalué à 1.
Et je ne parle pas du combo magique FORTRAN + MPI, avec des gens qui utilisent les I/O asynchrones pour aller plus vite (ce qui est bien) mais en pratique font des MPI_send(...) ; MPI_wait(...); (pas bien, gérer les I/O async en synchrone, faut le faire quand même).
Et justement, FORTRAN permet peut-être la performance, mais dans le cadre du HPC, si t'es pas foutu d'optimiser ton code correctement (et c'est le problème de beaucoup de scientifiques non informaticien, et oui c'est normal, puisqu'ils ne sont pas infoteux), tu perds tellement de temps lors de l'exécution qu'on se demande bien à quoi peuvent servir tous ces mécanismes faits pour rendre le calcul efficace.
[^] # Re: Le Fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Aujourd'hui, en Fortran, on s'en sort plus ou moins bien et c'est exactement ce que j'ai dis dasn un post. Pour pouvoir profiter de la future machine pétaflop, il faut modifier notre manière de programmer, la machine ne peux pas complètement s'adapter malleureusement à notre manière actuelle.
Le langage que j'ai beaucoup aimé était Sather avec une version pSather. L'objetif de ce langage était clairement de faire un langage objet à la Effeil mais très orienté calcul intensif et parallèle. Malheureusement, il est mort.
Pour ce qui est des bibliothèques de base comme BLAS ou Lapack, cela évolue, lentement mais surement. Je connais des gens qui ont leur propres versions moins optimisé mais qui ne veulent pas en changer car leur bibliothèque est validé depuis des années. Il faut dire que tu veux éliminer toutes erreurs possibles lorsque tu lances un calcul qui dure plusieurs semaines sur une machine SMP. Un des problèmes ici est que les chercheurs manquent de ressources de calculs (et aussi de bras) et qu'ils ne peuvent pas par exemple se permettent d'utiliser 40 coeurs pendant 3 semaines de la machine NEC SX8 de l'IDRIS pour rien.
Il faut bien voir que ce ne sont toujours pas des chercheurs en informatique qui font du Fortran mais plutôt des chercheurs du domaine des études faites. Les contrats de recherche qu'ils obtiennent ne sont pas destinés à financer l'amélioration de BLAS par exemple.
[^] # Re: Le Fortran
Posté par lasher . Évalué à 2.
Ben justement. La concurrence n'est pas meilleure du point de vue langage. Du point de vue des bibliothèques qui vont bien, le C est muni depuis un bout de temps de machins types threads, de bibliothèques à deux niveaux pour les threads, etc.
Pour ce qui est des bibliothèques de base comme BLAS ou Lapack, cela évolue, lentement mais surement.
Mouais. Pour ne prendre qu'une bibliothèque ultra-utilisée, à savoir hypre, peut-être bien que les préconditionneurs sont vraiment géniaux, mais en ce qui concerne les BLAS, ils ont fait un simple f2c d'une implémentation « libre » qui date de ... 1977. Ça fait peur, vraiment.
Pour ce qui est de l'argument des bibliothèques moins bonnes mais qui au moins n'ont pas de bugs, pour ne reprendre que des briques de base (oui, encore les BLAS ;-)), on se retrouve à la fin avec des gens qui ont des algorithmes qui ne passent pas du tout à l'échelle (parce que passer sur 16 ou 32 processeurs n'assure pas du tout que ça pourra passer au-delà), et qui vont être tout content de quadrupler le prix de leur calculateur, en doublant les processeurs ainsi que le système de refroidissement qui va avec, pour finalement obtenir une accélération de ... deux (je parle de machines qui sont déjà équipées d'au moins 16 ou 32 processeurs, justement).
Il faut bien voir que ce ne sont toujours pas des chercheurs en informatique qui font du Fortran mais plutôt des chercheurs du domaine des études faites. Les contrats de recherche qu'ils obtiennent ne sont pas destinés à financer l'amélioration de BLAS par exemple.
Et c'est bien ce que je leur reproche -- silencieusement, parce que le sismologue qui explique qu'il n'est pas informaticien, mais qu'il a codé tout son machin de maillage adaptatif en FORTRAN/MPI a quand même tout mon respect, optimisation ou pas optimisation.
Je sais bien qu'il s'agit de scientifiques autres que des infoteux qui codent tout ça (ce qui explique aussi pourquoi ils font toujours du FORTRAN). N'empêche : embaucher quelqu'un (un ingé de recherche) pour reprendre les bibliothèques fondamentales et les optimiser pour des architectures d'aujourd'hui (parce que le NUMA, avec l'hypertransport et le futur CSI d'Intel, c'est vraiment aujourd'hui) ne serait pas du luxe. D'ailleurs, certains labos l'ont compris, et commencent à prendre des gens compétents dans le domaine de l'optimisation.
[^] # Re: Le Fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Pour avoir fait du C++, c'est facile et rapide de transformer un code bien écrit en une soupe horrible et peu performante...
Il est clair qu'il manque d'ingénieur de développement (et aussi d'ingénieur système pour pas que le dev fasse du système) dans les laboratoires non liés à l'informatique directement et hors grand équipement de type physique (l'IN2P3 a quand même des moyens que les autres n'ont pas).
Pour être positif, il y a quand même des bibliothèques qui bougent, par exemple, en prenant la bonne version de la fftw, on a facilement un facteur 2 à 3 sur un code, et cela, qu'on soit en Fortran ou en C ;-)
Par contre, ce qui est pénible en Fortran, c'est que le mapping des fonctions dans les .o n'est pas normalisé donc il faut se tapper de recompiler les bibliothèques pour chaque version de compilateur. Lorsqu'on fait un nouveau langage, cela devrait être dans les spécifications de base.
[^] # Re: Le Fortran
Posté par med . Évalué à 4.
[^] # Re: Le Fortran
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je vais me faire incendier, mais le C, c'est un peu pareil, insupportable et bourré d'archaïsmes ;-) D'ailleurs, comparativement au Fortran, le C a vachement evolué !
[^] # Re: Le Fortran
Posté par - - . Évalué à 3.
le C n'est pas l'alpha et l'omega de la programmation (et encore heureux) même si je vous recommande de l'apprendre, hein (je dis ca aux petits jeunes qui lisent linuxfr :) )
[^] # Re: Le Fortran
Posté par Matthieu Lemerre . Évalué à 3.
Les premieres versions de fortran n'avaient pas de if then else qui a ete invente plus tard avec Lisp, c'est dire l'etat de l'art en langage de prog de l'epoque.
# Article du Turing Award
Posté par Zakath (site web personnel) . Évalué à 10.
En deux mots, il explique pourquoi les langages basés sur un ordinateur vu comme une machine de Von Neumann (un cpu, une mémoire et un bus de communication entre les deux) présentent de nombreux défauts, et pourquoi selon lui les langages fonctionnels sont extrêmement prometteurs.
C'est pas très long et bien écrit, bien argumenté et sans trop de trolls, donc si le sujet vous intéresse, n'hésitez pas à y jeter un oeil.
[^] # Re: Article du Turing Award
Posté par reno . Évalué à 2.
> [ coupé ]
> sans trop de trolls
Pour rétablir la moyenne en troll:
Petit coups d'oeil a la date du papier: 1978.
En pourcentage, on utilise probablement encore moins les langages fonctionnels en 2007 qu'en 1978, c'est une promesse longue à réaliser.
Bon plus sérieusement, il est vrai que certains concept promus par les langages fonctionnels ont été adopté par des langages utilisé par le commun des mortels: Ruby, etc.
Et Scala est probablement un des seuls langages fonctionnel (hybride en fait) qui m'a intéressé, les autres bof..
[^] # Re: Article du Turing Award
Posté par Zakath (site web personnel) . Évalué à 7.
Par ailleurs, des langages comme Haskell, scheme ou OCaml sont utilisés par le commun des mortels. Pas autant que C++, java ou même python, mais tout de même de manière non-négligeable.
[^] # Re: Article du Turing Award
Posté par yim yom (site web personnel) . Évalué à 2.
Ces langages utilisent un mecanisme d'evaluation d'expression tres puissant qui leur permet de reproduire tout simplement une notion de programmation fonctionnelle.
Pour resumer, la notion de "procedure" n'existe pas en C mais seulement la fonction. Alors pour aider un peu on a ajouter des function dite void qui ne renvoit rien et qui font comme les procedures (au sens pascal par exemple). Ca n'en reste pas moins des fonctions. Pour le reste tout est fonction et un expression et simplement la combinaison de fonctions. Ceci permet l'evaluation d'expression composees tres complexes et qui s'optimisent fortement. C'est une des forces mal connues du C. Essayez l'exercice qui consistent a concevoir la majeure partie d'un algorithme C en terme d'evaluation d'expressions (comme vous le feriez en Lisp).
Je vous conseille la lecture d'un bouquin bien vieux maintenant mais qui reste une reference agreable sur le C, qui s'appelle simplement le langage C aux editions Dunod ecrit par un D. Galland. La premiere partie de ce bouquin prend le contre-pied de la plupart des autres bouquins en presentant d'abord l'evaluation des expressions en C puis ensuite les instructions de controle de flot (for, if, while, etc...). Ca donne une idee de cette notion tres puissante d'expression.
Ce que je dis s'applique en gros aux autres langages comme C++, Java, C# et tout ceux qui se sont fortement appuyes sur le C (c'est aussi sans doute valable ailleurs mais je ne sais pas).
De la a dire que le C = Lisp, il n'y a qu'un pas a franchir et je le fais volontiers dans de nombreux cas. :-)
[^] # Re: Article du Turing Award
Posté par moksha . Évalué à 3.
En C pour faire ca il faut se priver d'utiliser des variables statiques dans tes fonctions, ce qui est relativement contraignant, et que le compilateur puisse le detecter pour faire des optimisations du genre func(a,b) + func(a,b) equivalent a 2 *func(a,b)
[^] # Re: Article du Turing Award
Posté par Guillaume Gimenez (site web personnel) . Évalué à 2.
int func (int, int) __attribute__ ((pure));
mes 2 cents
[^] # Re: Article du Turing Award
Posté par Hal9000 . Évalué à 7.
L'element de base indispensable (en pratique) a la programmation fonctionnelle, c'est la possibilite de definir des fonctions a la volee (on appelle ca lambda-expressions), et ca le C ne sait pas faire (contrairement au Python, par exemple).
Sans vouloir t'offenser, je ne suis pas sur que tu ais vraiment compris ce qu'est la programmation fonctionnelle, car ca n'a rien avoir avec le fois de pouvoir definir des fonctions, comme ton 3eme paragraphe le suggere. Ca, tous les langages le font. Cela dit, j'ai peut-etre simplement mal interprete ton message.
Ce qui caracterise la programmation fonctionnelle, c'est que _tout_ est fonction, au sens strict du terme, c'est a dire sans effet de bord. En particulier, la notion d'affectation de variable n'existe pas. Je renvoie le lecteur a l'article "Programmation Fonctionnelle" de Wikipedia, il n'est pas trop mal fait.
# [] --->
Posté par wahnby . Évalué à 10.
---> []
[^] # Re: [] --->
Posté par Victor STINNER (site web personnel) . Évalué à 9.
[^] # Re: [] --->
Posté par Édouard Siha . Évalué à 3.
[^] # Re: [] --->
Posté par Jiel (site web personnel) . Évalué à 5.
[^] # Re: [] --->
Posté par l0stman . Évalué à 2.
God is REAL unless declared INTEGER
(Dieu est réel à moins d'être déclaré entier)
# C'est encore rare les décès de célébrités de l'informatique.
Posté par Jorkar . Évalué à 3.
[^] # Re: C'est encore rare les décès de célébrités de l'informatique.
Posté par lurker . Évalué à 4.
Dijkstra, Backus, Khan, Knuth, Wirth, Hoare, Milner, Wadler, Cousot, McCarthy...
(Liste partielle, partiale et désordonnée)
[^] # Re: C'est encore rare les décès de célébrités de l'informatique.
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
# Et inventeur de la fondue du même nom...
Posté par ouah (site web personnel) . Évalué à -1.
Algol est aussi le premier langage qui a permis de faire de la récursion.
Et je crois que c'est aussi le premier qui a introduit la fameuse boucle 'for'.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.